Codecov Report

Attention: Patch coverage is 55.53914% with 602 lines in your changes missing coverage. Please review.

Project coverage is 70.59%. Comparing base (41ce248) to head (e19772f).

✅ All tests successful. No failed tests found.

@@            Coverage Diff             @@
##             main     #285      +/-   ##
==========================================
- Coverage   72.14%   70.59%   -1.56%     
==========================================
  Files         117      128      +11     
  Lines        9992    11011    +1019     
  Branches      597      644      +47     
==========================================
+ Hits         7209     7773     +564     
- Misses       2780     3231     +451     
- Partials        3        7       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🎉 The code now dehydrates to the client so it can render without JavaScript!

🎉 The code now dehydrates to the client so it run without JavaScript!

Wow 😵‍💫 and what about codetab

It rehydrates and runs with JS, but if you don't have JS, you can still view the docs. I used React's SSRing

@AugustinMauroy and I got search to finally work 🎉

@nodejs/nodejs-website @nodejs/web-infra ChangeHistory and SideBar aren't implemented yet, so this is still a draft, but it's ready for you to take a look, so feel free to review :-)

Blocked by nodejs/node#59019, which, once I finish it, will adjust the formatting, which will need to be reflected here

That got merged ✨

Let's add only one item with a left arrow (i18n) "<-- Back to Website"

When clicking on the Node.js logo, it'll already take you back to the website1, did you want something more explicit?

Footnotes

1. Well, not on the preview page. It takes you to /, which will be the website, when this is deployed to nodejs.org/docs... ↩

Interesting, noted.

I also wanted to clarify, although #327 is not a blocker for this PR, we shouldn't adopt the new web generator till we get #327

Let's add only one item with a left arrow (i18n) "<-- Back to Website"

When clicking on the Node.js logo, it'll already take you back to the website1, did you want something more explicit?

Footnotes

1. Well, not on the preview page. It takes you to /, which will be the website, when this is deployed to nodejs.org/docs... ↩

Interesting, noted.

Apparently it does not, just goes to the / of the api docs tooling, or will it do because it is eventually doing /?

hold on, https://api-docs-tooling.vercel.app/documentation.html#stability-overview isn't generated

@avivkeller one feat request for the web generator:

Can we make these headers sticky? What I mean is while scrolling on the utmost parent level (i.e. class, or method) while scrolling the piece that contains the title, pill, history button and the type definition should be sticky... I think that'd make it easier for the user navigating on our huge docs what section they are even in?

hold on, api-docs-tooling.vercel.app/documentation.html#stability-overview isn't generated

Is that being generated by the legacy one? (Just OOC, or maybe we completely forgot it)

hold on, api-docs-tooling.vercel.app/documentation.html#stability-overview isn't generated

I mentioned it to @flakey5 on Slack a few days ago. I intentionally didn't implement it here (yet), since it's kinda broken on the legacy generator, a d I wasn't sure what approach to go with.

Is that being generated by the legacy one? (Just OOC, or maybe we completely forgot it)

Yes, we have the logic to generate it, No, it is not being generated. Because we generate each file individually (for Makefile caching reasons), the legacy generator does not take in all the files, and hence, cannot get the stability for each one, and does not end up generating this section.

My proposed solution was to abandon it, and manually set the stabilities in node core's index.md file.

@ovflowd Signature box for classes, WDYT?

Apparently it does not, just goes to the / of the api docs tooling, or will it do because it is eventually doing /?

It redirects to /, since, in production, https://nodejs.org/ is the website, not the docs.

My proposed solution was to abandon it, and manually set the stabilities in node core's index.md file.

You mean manually writing down the stability of each one of the modules? Noted... But how the current tooling does that if Makefile also uses only individual files? Or does it also fail currently for individual files? I don't recall tbh.

But how the current tooling does that if Makefile also uses only individual files? Or does it also fail currently for individual files? I don't recall tbh.

See https://github.com/nodejs/node/blob/4102dcc2269d12cb576468370419b059c31e72b0/tools/doc/stability.mjs, which uses the generated all.json file to generate index.html.

Can we make these headers sticky? What I mean is while scrolling on the utmost parent level (i.e. class, or method) while scrolling the piece that contains the title, pill, history button and the type definition should be sticky... I think that'd make it easier for the user navigating on our huge docs what section they are even in?

I'd love to... but it's actually quite complex. If we use position: sticky, each header would need to define a background. If we use JavaScript, we'd, well need to add JavaScript. If you're fine adding more JS, then let's go for it.

Which is take more place. DO we have ability to detect this case and don't duplicate it or merge it

Which is take more place. DO we have ability to detect this case and don't duplicate it or merge it

I originally merged them, but we have so many different edge cases on node core, I'd rather follow-up with an issue adding:

• Lint
• Formatting Core

Before implementing such a feature. It's a lot of work to resolve the edge cases, and I don't want that to break this, and block it from merging.

Which is take more place. DO we have ability to detect this case and don't duplicate it or merge it

I originally merged them, but we have so many different edge cases on node core, I'd rather follow-up with an issue adding:

• Lint
• Formatting Core

Before implementing such a feature. It's a lot of work to resolve the edge cases, and I don't want that to break this, and block it from merging.

What if we only handle the non-edge cases? Would that make sense?

Also

nit: Can Return not be in a <code> since it is not a property, but the return value?

What if we only handle the non-edge cases? Would that make sense?

No, I don't think that would. The edge cases are headers that have slightly different descriptions/history/whatnot, and would require additional logic to merge / not to merge. You can't, in my eyes, handle the non-edge cases without accounting for the edge-cases, so it would be easier (IMO) to handle it all in a follow-up.

FYI I made a new milestone, and will open / am opening follow-ups